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Abstract. In the (discrete) CNN problem, online requests appear as 
points in R^. Each request must be served before the next one is revealed. 
We have a server that can serve a request simply by aligning either its 
X or y coordinate with the request. The goal of the online algorithm is 
to minimize the total Li distance traveled by the server to serve all the 
requests. The best known competitive ratio for the discrete version is 
879 (due to Sitters and Stougie). 

Wo study the continuous version, in which, the request can move con- 
tinuously in K'^ and the server must continuously serve the request. A 
simple adversarial argument shows that the lower bound on the compet- 
itive ratio of any online algorithm for the continuous CNN problem is 
3. Our main contribution is an online algorithm with competitive ratio 
3 + 2^/3 ~ 6.464. Our analysis is tight. The continuous version general- 
izes the discrete orthogonal CNN problem, in which every request must 
be a; or 2/ aligned with the previous request. Therefore, Our result im- 
proves upon the previous best competitive ratio of 9 (due to Iwama and 
Yonezawa) . 

1 Introduction 

The fc-server problem has been influential in the development of online algo- 
rithms [3]. We have k servers that can move around a metric space. Requests 
arrive in an online manner on various locations in the metric space. After each 
request arrives, one of the k servers must move to the request location. The 
online algorithm must make this decision without any knowledge of the future 
requests. The objective is to minimize the sum of the distances traveled by the 
k servers. 

A natural variant of the fc-server problem, the (discrete) CNN problem, was 

introduced by Koutsoupias and Taylor [4]. The name derives from the following 
illustrative example: consider a sequence of newsworthy events that occur in 
street intersections in Manhattan. A CNN news crew must cover these events 
with minimal movement. Since they have powerful zoom lenses, they only need 
to be at some point on either one of the two cross streets. More formally, we are 
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given a sequence of requests as points from that appear in an online manner. 
We have one server that can move around in M^. To serve a request, the server 
must merely align itself to the x or y coordinate of the request. The objective is 
to minimize the total distance traveled by the server in Li norm. 

There is an equivalent alternative definition that is also used in literature in 
which, instead of a single server that can move in 2D, we have two independent 
servers with one restricted to move along the cc-axis, while the other is restricted 
to move along the y-axis. Given an online request at (a, 6), either the x-axis server 
must move to x = a or the y-axis server must move to y = b. The objective is 
to minimize the sum of distances moved by either servers. Notice that the two 
independent servers in different dimensions are equivalent to a single server that 
can move around in both dimensions. For this reason, the CNN problem is also 
called sum of two 1-server problems [4]. 
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Fig. 1. Illustration for the two server definition of the continuous CNN problem. 



We introduce the continuous version of the CNN problem. We use the al- 
ternative two server definition to illustrate the contimioiis version. Consider the 
problem of covering the activities of a soccer match (see Figure 1). For the sake 
of simplicity in our illustration, let us have two cameras on rails, one along the 
length (i.e., the .x-axis server) and the other along the breadth (the j/-axis server) 
of the field. Their orientations are fixed perpendicular to the direction of move- 
ment (of course, pointing into the field). As the ball is kicked around, at least one 
of the two cameras must track the ball continuously. Informally, the inpiit is a 
request point moving along a continuous trajectory that is revealed in an online 
manner and a server must continuously align itself to the x ov y coordinate of 
the request. 

We say that two points are cc-aligned (respectively, j/-aligned) if they share 
the same x (respectively, y) coordinate. Also, we say that two points are aligned 
if they are either x-aligned or y-aligncd. We are now ready to formally define 
the continuous CNN problem. For this formal definition (and for the rest of the 
paper) we have a single server that can move around in 2D space. Our input is an 
online sequence of pairs = (p^, di), where pi is a point on pi-i + tdi^i, t>Q, 
and di is a unit vector in some arbitrary direction. (In the soccer illustration, pi 
is the point on the previous trajectory where the ball is intercepted and di is the 



new direction in which it is kicked.) Without loss of generahty, the first point is 
assumed to be the origin. The server also starts at the origin. When an input pair 
{Pi,di) is revealed, the server and Pi are already aligned. The online algorithm 
must then commit to a continuous trajectory Ti{t) of the server parameterized by 
t such that for all t > 0, Ti(t) is aligned with pi +tdi. After the online algorithm 
commits, the next request {pi+i,di+i) arrives, the online server moves to the 
point on Tj that aligns with pi^i along the trajectory Tj. The objective is to 
minimize the total distance traveled by the server in Li norm. 

History of CNN problems: The discrete version of the CNN problem was dis- 
cussed in several conferences and seminars in the late 1990s without any break- 
throughs[l, 2]. It was formally introduced by Koutsoupias and Taylor [4]^. They 
conjectured that this problem has a competitive algorithm along with a lower 
bound of 6 + vTz on the competitive ratio of any deterministic online algo- 
rithm. Their conjecture was proved affirmatively in [5] by Sitters, Stougie, and 
de Paepe, albeit, with an algorithm that was 10^-competitive. For a fascinating 
discussion of the prevailing understanding of this problem in 2003, see [1]. Even- 
tually, Sitters and Stougie [6] made further improvements and provided a 879- 
competitive algorithm. In fact, their work focussed on the generalized k-server 
problem which can be characterized as the sum of several 1-scrvcr problems on 
arbitrary metric spaces. The orthogonal CNN problem was introduced by Iwama 
and Yonezawa [2]. Each request (except the first one) must either share the x 
coordinate or the y coordinate with the previous request. With this restriction, 
they were able to improve the competitive ratio dramatically to 9. 

Our Contribution: We focus on the continuous CNN problem, which is a gen- 
eralization of the orthogonal CNN problem. We formalize this in the following 
Claim (with proof deferred to the Appendix). 

Claim 1. Any c-competitive algorithm A for the continuous CNN problem can 
be applied to the orthogonal CNN problem in a manner that preserves the com- 
petitive ratio. 

A typical adversarial argument gives us the following lower bound on the com- 
petitive ratio. 

Claim 2. If there is a c-competitive algorithm for the continuous CNN problem, 
then c > 3 even on a unit square. 

In Section 2, we introduce a simpler problem called the unit CNN problem and 

prove a lower bound of 3 on its competitive ratio in Theorem 4. The proof of 
Theorem 4 can be easily adapted for Claim 2. 

We now provide an example that informally illustrates how we get a lower 
bound of 3 on the competitive ratio of the continuous CNN problem; see Figure 2. 
Consider the unit square with both the optimal offline server and the online 
server at the top-left corner. In this adversarial example, the request moves to the 
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bottom-right corner so that the onhne server is forced to choose between either 
a clockwise or counter-clockwise direction. Assume, without loss of generality, 
that it chooses the clockwise direction and moves to the top- right. The offline 
server, however, makes a single move down to the bottom-left. Suppose now the 
request moves around repeatedly in the left and bottom edges of the unit square, 
i.e., it makes a repeated "L" shaped move. Clearly, the offline server is already at 
a "sweet spot" and therefore stays unmoved. The online server, however, must 
correct its position and move to the sweet spot to offset its disadvantage. Notice 
that the online server moved three units of distance while the optimal offline 
server just needed just one. 
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Fig. 2. The figure on the left shows the request trajectory. The figure on the right 
shows the trajectory of online and offline servers. 



The significant contribution of our paper is an online algorithm for the con- 
tinuous CNN problem with a competitive ratio of 3 -|- 2\/3 = 6.464. In light of 
Claim 1, OUT rcsiilt improves upon the 9-compctitivc algorithm for the orthogo- 
nal CNN problem [2]. Our algorithm alternates between two phases, namely, the 
bishop phase and the rook phase. Hence, we call it the Bishop-Rook algorithm or 
just the BR algorithm. Our analysis using a non-decreasing potential function 
is non-trivial. Finally, we show that our analysis is tight by constructing input 
instances for which the competitive ratio is realized. 



Organization of the paper: In Section 2, wc introduce a simplified problem called 
the unit CNN problem. We prove a lower bound of 3 on the competitive ratio 
of algorithms for the unit CNN problem, from which, the lower bound of the 
continuous CNN problem follows quite immediately. In Section 3 we present the 
BR Algorithm for the continuous CNN problem. We analyze the BR algorithm in 
Section 4 and show that it has a competitive ratio of (3 -|- 2\/3) w 6.464. 



2 Preliminaries: Lower Bound 

The lower bound for the competitive ratio of the continuous CNN problem (see 
Claim 2) is 3. As it turns out, this lower bound shows up in a much simpler 
problem that wc call the unit CNN problem. We provide the lower bound proof 
for the unit CNN problem (Theorem 4) which easily encompasses Claim 2. For 
the sake of completeness, we state the upper bound for the unit CNN problem, 
but defer all details and proofs to the Appendix. 

In the unit CNN problem, a sequence of requests, {ri,r2, ■ ■ ■), appear online 
as points in M^. We have a server that must serve each request r, by moving to a 
location that is aligned vertically or horizontally with the request. Each time the 
server moves either horizontally or vertically, it has to pay $1 (regardless of the 
distance moved). If the move has both a horizontal and a vertical component, it 
pays $2. The objective of the server is to minimize; the total payment. We also 
consider the restricted version called the unit orthogonal CNN problem in which 
any pair of consecutive requests must either share an a; or y coordinate. 

We begin with a simple observation that we state without proof because, 
in essence, it has been noticed before by Iwama and Yonezawa [2]. Define a 
sequence of moves by any algorithm to be frugal if, for each move in the sequence, 
the payment is never more than the minimum required to serve the current 
outstanding request. Therefore, by definition, no frugal sequence of moves will 
include a $2 move. 

Observation 3. Given any sequence of moves that pays $d to serve the input 
sequence of requests, there is a frugal sequence that also pays at most $d to serve 
all the requests. 

Theorem 4. // there is a c-competitive algorithm for the unit CNN problem, 

then c > 3 even when the requests arrive in an orthogonal manner. 

Proof. For this proof, we limit ourselves to input instances in which the requests 
can only appear in the vertices of the unit square with the origin at its bottom 
left. Furthermore, wc restrict the requests to appear in an orthogonal manner, 
i.e., each request (except the first one) shares either an a; or y coordinate with 
the previous request. 

Given Observation 3, we can assume that the server will not move if it is 
already aligned to the request. Notice that an adversary can force the online 
algorithm to move at each step. We keep server one step away from each request 
Ti by placing next request rj+i diagonally opposite to the current position of the 
server. 

Given such a sequence of requests, an offline algorithm splits it into consecu- 
tive triples. The offline server moves at most once to service each triple r^-i, 
and rj_|_i. If possible, the offline server moves to rj in one step — it can service 
rj_i, r, and r^+i from rj. Such a one step move to r, is not possible only when 
the server and arc diagonally opposite each other, so the server must be within 
1 hop of both rj_i and rj+i. It simply serves rj_i from the current position and 
then hops to rj+i to serve both and r^+i. 



So, for every three steps of the onHne algorithm, the ofHine server requires 
at most 1 move, thereby completing the proof. □ 

Claim 5. There exists a 4-com,petitive algorithm for the unit CNN problem 

Claim 6. There exists a 3- competitive algorithm for the orthogonal unit CNN 
problem. 

3 The BR Algorithm for the Continuous CNN Problem 

We now turn our attention to the main problem that we address in this paper 

- the continuous CNN problem. Recall that wc formally defined the input as 
an online sequence of pairs {pi,di). Informally, we treat the request as a point 
starting at the origin and moving to each subsequent Pi in straight line segments 
whose direction is given by the vector d^. So wc use the term request trajectory 
to refer to the path traversed by the request. The server's trajectory must stay 
aligned with request trajectory at all times. In this section, we describe the 
Bishop- Rook algorithm or just the BR algorithm that alternates between two 
phases, namely, the Bishop phase and the Rook phase. As the name implies, 
the server moves diagonally during the Bishop phase. In the Rook phase, we 
treat the horizontal and vertical components of the server separately, leading 
to movements that mimic Rooks in Chess. The algorithm switches between the 
phases when appropriate conditions (described subsequently for each phase) are 
met. 

The key intuition behind the algorithm is the following. Suppose the offline 
server manages to get to a "sweet spot" from which it can align with the request 
trajectory with little or no movement. Then, the online server also must home 
into that spot. Iwama and Yonezawa [2] also exploit this idea. They get closer 
to a potential sweet spot using "L" shaped moves — hence, one can call it the 
Knight algorithm. To achieve this homing effect in the BR algorithm, we define 
an offset vector at the end of the bishop phase that, when added to the online 
server's position, will point to our candidate sweet spot. In the rook phase, we 
use the offset vector to guide the online server to the sweet spot. 

Bishop Phase: During the bishop phase, as the name implies, the server moves 

diagonally making a 45° angle with the axes. Without loss of generality, let the 
point Pi be at (0, 0) and the online server be on the non-negative part of y-axis 
at (0, /i), so /i > 0; see Figure 3. Throughout the bishop phase, the server moves 
in a manner that maintains x-alignment with the request trajectory. Notice that 
this defines the x component of the server movement. To ensure the diagonal 
movement of the bishop phase, the server also moves in the —y direction. For 
every maximal 5x that the server moves in cither the +x or —x direction, the 
server simultaneously moves a distance \5x\ in the —y direction. If (and when) 
the position of server and request trajectory coincide, we terminate the bishop 
phase and switch to the rook phase. Let {sx, Sy) be the coordinates of the point 
at which they coincide. Then, the offset vector o = —SxX, where x is the unit 
vector in the positive x direction. 



Fig. 3. Bishop pliase 



Fig. 4. Rook phase without offset 
update 




Fig. 5. Rook phase 
showing offset update 



Rook Phase: At the beginning of the rook phase, positions of server and request 
trajectory coincide. Without loss of generality we assume that offset is in the 
—X direction. We maintain two invariants throughout the rook phase. However, 
in so doing, we are judicious with the Li distance traveled by the server. 

y-alignment: The server and request trajectory are always y-aligned. This fully 
defines the movement of the server along the y direction because the server 
maintains the same y coordinate as that of the request. 

X coordinate inequality: The x coordinate of the server is always less than 
or equal to the x coordinate of the request trajectory. This invariant is more 
subtle. When the x coordinate of the request trajectory is strictly greater 
than that of the server, the server's x coordinate stays unchanged — this is 
to ensure that we are judicious with the Li distance traveled. When the x 
coordinates coincide and the request trajectory is moving in the —x direction, 
then the server moves along with the request trajectory. 

During the rook phase, the offset vector o decreases whenever the server 
moves. The rate of decrease depends on the horizontal and vertical components 
of the movement. The rate at which |o| decreases is given by: 



When |o| reaches 0, we switch to the bishop phase. Fig. 4 depicts the working 
of the rook phase, but does not show the change in offset . Fig. 5 shows how 
the offset shrinks as the phase progresses. 

4 Analysis of the BR Algorithm 

To simplify the analysis, we assume that we are working on an instance of the 
continuous orthogonal CNN problem, i.e, all the direction vectors are orthog- 
onal with respect to the axes. This does not affect our analysis because any 
straight line of arbitrary angle can be approximated by a series of infinitesimally 
small x and y components. 

Before we proceed with the analysis, we make a simple observation that 
allows us to insert artificial points into the input sequence. Suppose we are given 
a sequence of input requests / = ((pi, rfi), . . . , {pi, di), (pi+i, di+i), • . •)• Consider 
the sequence /' = (pi, di), . . . , (ft, dj), (p-, dj), (ft+i, dj+i), . . ., where lies on 
the line segment between and Pi+i - Then any server trajectory for serving the 
request sequence / will also serve /' and vice versa. 

Our analysis uses a potential function that is non-decreasing throughout the 
execution of the algorithm. We define a cycle to be the combination of a bishop 
phase and the subsequent rook phase. Recall that at the start of a cycle, the 
offset is 0. We re-orient our view such that the next outstanding request is at 
the origin and the online server is at (0, h), where h>0. When re-orienting our 




o| — (1 + \/3)|t| if server and request move a distance t vertically 

o| if request moves but server does not 

o\ — t if server and request move a distance t horizontally 



view, we ensure that the potential remains unchanged. This is shown formally 
in Remark 1. The potential function # is a function of the offset and the 
parameters defined as follows: 

(opt g^Yid are the distances traveled by the optimal offline server and the 

online server, respectively, 
popt g^jjjj pon g^j-g ^j^g positions of the optimal offline server and the online server, 

respectively. 

The potential function is given by 

^ = (3 + 2\/3)rf* - 3d(p°" + o,p°P*) - r" - |o| + /(|o|,p°f*,p°"), (1) 

where d{p, q) is the Li distance between points p and q. To define /, we first 
define h = — where and are the y coordinates of and 
Now, 

r if /i < 

f{o,p"P\p°'^) = < (6 - 2V3)/i if < /i < |o| 
[(6-2v^)|o| ii\o\<h 

Theorem 7. <!> is non- decreasing throughout the execution of the BR algorithm 
and this implies a competitive ratio of (3 + 2\/3) . 

We first provide a series of lemmas that lead to the proof of Theorem 7. 

Lemma 1. // the online server stays still, <P does not decrease. 

Proof. Note that o remains unchanged when the online server stays still. Also, 
the optimal server either (i) does not move, (ii) moves horizontally (arbitrary 
distance) or (iii) moves vertically the same distance that the request moves. In 
all three cases, does not decrease. □ 

Corollary 1. From Lemma 1, it follows that, in the bishop phase, $ does not 

decrease luhen request m,oves vertically. 

We define the offset halfplane to be the halfplane x < p°". Naturally, its 
complement is a; > Since can change as the online server moves, the 
offset halfplane also changes accordingly. 

Corollary 2. From Lemma 1, it follows that, in the rook phase, $ does not de- 
crease when request moves horizontally in the complement of the offset halfplane. 

Remark 1. At the start of each c;yclc, the axes of the euclidean plane can be 
redrawn (orthogonally) without changing 

Proof. At the start of each cycle, offset is 0. Therefore, only the first three 
terms of Equation 1 are non-zero. Those three terms do not change if the axes 
are redrawn orthogonal to the previous axes. □ 



In the rest of the lemmas, since we can insert new points into the request 
sequence, we show that # does not decrease for small e moves of the request in 
the direction specified. 

Lemma 2. In the bishop phase, (p does not decrease when the request moves a 

distance e in the horizontal direction. 

Proof. Wc treat this proof in cases based on the behavior of the optimal offiine 
algorithm. 

Case: is unchanged. This is only possible if p"^^ and request are y- 
aligned. is unchanged. increased by 2e. |o| has changed by at most 
e. f ~ because /i < 0. If the request moves in the same direction as o, 
then |o| decreases by e. d{p°" + o,p°P*) decreased by e. Overall, <1> does not 
decrease (see Fig. 6). 

Case: moves vertically and aligns with request. This is a composi- 
tion of Lemma 1 and the previous case (see Fig. 7). 

Case: p°P* < and and request are x-aligned for the duration of the move. 
£opi. jjjcj-Qases by e. If request moves in the same direction as o, then |o| de- 
creases by e and d(p°"' + o,p°P*) decreases by 2e, otherwise, |o| increases 
by e and rf(p°" + o,p°^*) is unchanged. (.""' increases by 2e. / remains at 0. 
Therefore, does not decrease (sec Fig. 8). 

Case: > and and request are a;-aligned for the duration of the move. 
£opt increases by e. If request moves in the same direction as o, then |o| de- 
creases by e and (i(p°" + o,p°''*) remains unchanged. Otherwise, |o| increases 
by e and d{p°"' + o,p°P*) increases by 2e. i""^ increases by 2e. kin f increased 
by e (see Fig. 9). 

The easy case is when |o| decreases. Wc assume that cither |o| > hor \o\ < h. 
Otherwise, we can insert a request when the change happens. With either 
option, the change in / term is positive and since |o| decreases, one can work 
out that (p increases. 

When |o| increases, the analysis tightens. The / term increases by (6 — 2-\/3)e 
because |o| and h also increase by e. Therefore, = (3 + 2\/3)e — 6e — 2e — 

e+(6-2v^)e = 0. 

Case: p°P* and request are x-aligned for the duration of the move. In this 
case, we are not restricting the relative locations of p°P* and In partic- 
ular, > p°P* first, then after some point, the inequality is interchanged. 
If we insert a request at that point, then, this case breaks into the previous 
two cases. 

□ 

Lemma 3. In the rook phase, does not decrease when request moves horizon- 
tally into the offset halfplane. 

Proof. As the request moves a distance e, the online server goes with it. (So, the 
request does not enter the offset halfplane, but rather pushes it by a distance e.) 
Therefore, |o| decreases by e. 
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Fig. 8. Case: p^''* < pT 
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Case: p"^* stays still. Clearly, p"^* is j/- aligned with the request. and 

-I- o^p°P^) are unchanged, but increases by e. Since p"^* and are 
y-aligncd, / = 0. Recall that |o| decreases by e. Therefore, # is unchanged 
(sec Fig. 10). 

Case: p°P^ makes a vertical move after which, p°P* and request are y-aligned. 

We can assume that p°^* made the jump first before p°^ moved along with 

the request. Prom Lemma 1, # does not decrease when jumped. 

moving along with the request is handled by the previous case (sec Fig. 11). 
Case: p^^* makes an x-aligned move. and f"" increase by e. -|- o,p°^*) 

decreased by e. Since |o| decreased by e, / decreases at most by (6 — 2\/3)e 

(see Fig. 12). Therefore, 



A{^) > (3 -h 2^3)6 + 2,e + e-e-{Q- 2^3)6 > 0. 



□ 



Lemma 4. In the rook phase, $ does not decrease when request moves vertically. 

Proof. Note that all vertical moves of e distance in the rook phase decrease |o| 
by (1 + V3)e. 
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Fig. 10. Case: stays still 



Fig. 11. Case: p"^* moves vertically 
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Fig. 12. Case: makes an a;- 

aligned move 



Case: p°P* < p°J^ and is x-aligned and therefore does not move. 1°^^ 

is obviously unchanged, but increases by e. + o,p°^*) decreased 

by at least (1 + \/3)e - e = \/3e. Since /i < 0, A{f) = 0. Therefore, 

Z\(<?) > SVSe + VSe>0 (sec Fig. 13). 
Case: > and is x-aligned, so it does not move. and request move up by e. 

As in the previous case, £°^* remains unchanged, but increases by e. Also, 

|o| decreased by (1 + V^)e. dip'""' + o,p°'P^) decreased by (1 + \/3)e + e = 

2e + VSe. Both /i and |o| decreased, so / decreased as well by at most 

(1 + VS){6- 273)6 (see Fig. 14). Therefore, 

A{<P) > 3(2 + V3)e - e + (1 + V3)e - (6 - 2y3)(l + V3)e > 

Case: p°P* is still, but p°" and request start below p°P*, move up and cross over to above p"P*. 

This is simply a composition of the above two cases, so does not decrease. 
Case: p"^* > and is a;-aligned, so it does not move. and request move down by e. 

£opt unchanged, but £°" increases by e. |o| decreased by {l+^/3)e. d{p°^ + OjP^P*) 
decreased by (1 + •\/3)e — e = v^e. While h increases, |o| decreased. There- 
fore, / might decrease, but at most by (1 + \/3)(6 — 2\/3)e. Therefore, 
Z\(<?) > 3\/le + \/3e ~ (1 + %/3)(6 - 2v^)e = (see Fig. 15). 
Case: starts out y-aligned, but it a;-aligns itself to the request with a horizontal move. 
This case can be viewed as the composition of two parts, p"^* moves first 
and ^ docs not decrease (by Lemma 1). Then, p°P* stays still, but request 
and server move up. This is the previous case. Hence, does not decrease 
(see Fig. 16). 



Case: p°'P^ moves vertically (up or down) and stays y-aligned. i'"^* and 
fion incj-Qa^e by ^ |o| decreases by (1 + V3)e, but + o,p°P^) increases by 

at most (1 + \/3)e. Finally, / remains at 0. Therefore, Zi(#) > (3 + 2y/2,)e - 
3(l + y3)e-e + e + y3e = (seeFig. 17). □ 
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Fig. 15. Case: p^"* > p°" and p°^* 
is a-aligned. p°" moves down 
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Fig. 16. Case: p"*"* x-aligns with a 
horizontal move 



Fig. 17. Case: p"*** moves vertically 



Proof (of Theorem 7). <1> started at and, from Lemmas 1, 2, 3, 4, and Corol- 
lary 2, we know that it only increased. Without loss of generality, we can as- 
sume that wc terminate at the end of the rook phase, at which point, the / 
function will evaluate to 0. If we terminate at some other point in the cycle, 
/ might be non-zero. For the purpose of analysis, we can perform a simple 



trick to bring / to zero without increasing . In particular, we artificially 
move the request repeatedly in an "L" shaped manner with at the cor- 
ner, p"" will home in on this corner point as well and once it coincides with 
the corner, / will become zero without incurring any increase in 1°^*. Since 
# = (3 + 2\/^)rP* - 3d(p°" + o,p°P*) - r" - |o| > 0, and + o,p°f*) and 
|o| are non negative, (3 + 2y/2,)£°P* > T". □ 

Rem,ark 2. The analysis of our algorithm is tight, i.e. there are infinite sequences 
of requests for which = (3 + 2a/3)£°p*. 

Proof. Wc provide two different sequence of input. Our first sequence starts with 
p°^^ at the origin. and request are at (0, 1) and we are at the beginning of 
the bishop phase. Then request moves to (0,0) and then to (1,0). makes a 
diagonal move to (1,0), but does not move. So, has increased by 2, but 
stays unchanged. At this moment our algorithm is in the beginning of the 
rook phase with o = — x, where x is the unit vector along x-axis. Request moves 
from (1,0) to (1,-r^); P""* moves together with it from (0,0) to (0, -^). 

l~l~vo l-|-v3 

According to our algorithm should follow after the request and at the end 
of its move o becomes 0. Thus we get to the bishop phase of our algorithm. 
and have both increased by j^^- Note that we are back in the situation 
that we started, so the adversary can repeat this sequence ad infinitum. In each 
cycle, has increased by and increased by 2 + length in total. 

Therefore, ^ = (2+ ^)(l + x/3) = 3 + 2\/3. □ 

In the proof of Remark 2, we provide two tight examples (although the sec- 
ond example is deferred to the Appendix) to indicate how balances between 
multiple scenarios. We feel that minor adjustments to will not reduce the 
competitive ratio. 
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Appendix 



Proof (of Claim 1). Recall that, in the orthogonal CNN problem, any two con- 
secutive pairs of requests must share either the same x or y coordinate. Given 
an online input sequence lortho = {Pi^Pi, ■ ■ we must construct an online se- 
quence of requests Iconi. for the continuous CNN problem. When a new request 
Pi arrives in lortho, we construct the next request in Icont as follows: (ft-i, di-i), 
where dj-i = is the unit vector in new direction. Clearly, the request 

trajectories in both the orthogonal and the continuous CNN problem instances 
are exactly the Scinie. Therefore, B^ny online algorithm J\. for Icont 

can also be 

used for lortho- □ 

For the purpose of this proof, we restrict requests to appear in an orthogonal 
manner, i.e., each request (except the first one) shares either the same x or y 
coordinate as the previous request. 



Second tight instance for Remark 2: The second sequence is as follows. Both p°^* 
and p"" be at (0, 1) in the beginning of the bishop phase. The request is at the 
origin. Then request moves to (1,0) and moves to (1,0) and increases by 
2; p°'P* moves to (1, 1). At this moment our algorithm is in the beginning of the 
rook phase with o = — x. Request moves from (1,0) to (1,— ]^pyj); OPT stays 
still. Server follows after the request untile o = 0. Thus we get to the bishop 
phase of the algorithm. Then request moves to (1, 1); and stay. Then, 
request moves to (— -^^^ ^ 1) and finally returns back to (1,1); J)"^* stays still; 
pon jj^Qygg (1,1) at a total length 3(1 + ^If^)- At this point, wc arc again 
at the beginning of the bishop phase. Then request moves to (say) (1,0) and we 
are back to the starting situation, i.e., we are in the bishop phase with and 
coinciding and arc at unit distance away from the request. Hence, this cycle 
can be repeated ad infinitum. Clearly, = 4(1 + 77775) + 1 = 3 + 2-\/3. 



The Unit CNN Problem 



Proof (of Claim 5). Wc now provide a 4-competitive online algorithm. Our al- 
gorithm works in cycles. In each cycle, the online algorithm pays at most $4 . 
Therefore, to prove that the algorithm is 4-competitive, we have to simply show 
that the offline optimal algorithm must pay $1 per cycle. The intuition behind 
the algorithm is as follows. In each cycle, for the offline algorithm to avoid pay- 
ing, there must be a sweet spot in such that if the offline server were located 
there, it would not have to move throughout the cycle. The goal of the online 
algorithm is to discover such a position (if it exists) and reach it in at most four 
$1 steps. The next cycle starts either (i) when the online algorithm establishes 
that there is no sweet spot (so the offline server has moved), or (ii) when the 
offline server cannot serve a request from the sweet spot (again, requiring the 
offline server to move). 



Formally, the algorithm works as follows. Assume that we are at the start of a 
cycle and the first request in that cycle, ri , has arrived. We also assume that the 
offline algorithm has positioned its server in the advantageous sweet spot. The 
online algorithm pays $1 (if required) and aligns with the Xi. We assume that 
r2 does not share the same x coordinate with ri. If it does, the server need not 
move and it can be discarded from the input sequence (for analysis purposes). 
When r2 = (2:2,2/2) arrives, the online server moves to {xi,y2) and serves r2- If 
2/1 ~ y2i then the sweet spot (if it exists) is somewhere on y = yi = y2] this is 
case A. Otherwise, the sweet spot is either {x\,y2) or (2:2,2/1); this is case B. 

Suppose we are in case A. Then we assume that r^, — (2:3, 2/3) does not share 
the y coordinate with r2; if it did, the online server need not move and can 
be discarded for analysis purposes. The sweet spot must be (2:3,2/1). The online 
algorithm can reach it in one step and stays there till a request that it cannot 
serve from (2:3,2/1) arrives. The cycle is over. 

Suppose we are in case B. If the third event = (2:3,2/3) does not share 
either an 2: or 2/ coordinate with n or r2, then clearly, there cannot be a sweet 
spot; the cycle is over. Suppose, instead, that shares the x coordinate with 
r2; other subcases can be seen symmetrically. Then, the sweet spot is (2:2,2/1)- 
Then, the online algorithm pays $2 and moves to (2:2,2/1)- Again it stays there 
until forced to move when the cycle is over. Claim 5 (stated in Section 2) follows 
in a straightforward manner. Furthermore, there are instances for which the 
competitive ratio 4 can be realized, but we defer their description to the full 
version. □ 

Proof (of Claim 6). Suppose the sequence of events is guaranteed to be orthog- 
onal, i.e., each request shares a coordinate with the previous request. Then, we 
provide a very simple and tight algorithm with competitive ratio 3. The algo- 
rithm is very simple. The online server does not move unless the event is not 
visible to it. In that situation, it moves to the last event that it could see. By the 
orthogonality condition, we know that this algorithm is correct. Our claim that 
this algorithm is 3-competitive is along the same lines as the previous theorem, 
only simpler. 

We claim that for every consecutive sequence of moves worth $3 in our al- 
gorithm, OPT has to do at least one $1 move. The proof is similar to that of 
Claim 5. Consider four consecutive orthogonal requests (^o, ri, r2, rs); note that 
adjacent requests must be at distinct locations. At the start of the cycle, both 
online and offline servers are in some position to serve tq. We assume for the 
sake of contradiction that the offline algorithm has positioned itself so it does 
not have to move for the next three requests. The online server will move from 
its current position to vq ^ r\ ^ r2 to serve ri, r2, and r^, respectively. For the 
offline optimal algorithm to have served this sequence without moving, it must 
be in a position to see all four requests. The only candidate for the first three 
requests is ri, while the only candidate for the second three requests is r2- Since 
we require adjacent requests to be distinct, this is a contradiction. □ 



